Q: When using Rendezvous APIs like CFNetServices, NSNetServices and DNSServiceDiscovery, what should I pass in for the domain parameter?A: A: Normally, when Registering and Browsing for services, you should pass in an empty string ("") for the domain, and the system will automatically do the correct thing. In Mac OS X 10.2 through 10.3.x, using an empty string will cause the system to Register and Browse for services in the Multicast DNS "local." domain. In addition, by passing in an empty string for the domain, your application will automatically take advantage of future enhancements to Rendezvous. When Resolving a service, make sure to pass in the same domain which was returned in the Browse callback when you originally discovered the service. Don't assume that all services are in the 'local.' domain. If you hard code "local." as the domain for Resolving, your application might not be fully compatible with future versions of Mac OS X. In some cases, you may want to prevent your application from operating outside the local network. For example, iTunes must only share music with other computers on the local link. In cases like this, you can restrict Rendezvous service discovery to the local network by explicitly passing in "local." for the domain parameter when Registering and Browsing. IMPORTANT: A small number of shipping applications are passing in an invalid domain when Registering and Browsing. Even though everything seems to work correctly from a high level, by using an invalid domain these applications are generating illegal Multicast DNS packets. Specifically, the domains "local.arpa" and '.local' (with the dot in front of "local.") are invalid. Any application which uses these domains will stop working in future versions of Mac OS X. Document Revision History| Date | Notes |
|---|
| 2004-02-06 | New Document |
Posted: 2004-02-06
|
